home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 14250 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  8.8 KB
  1. Path: news.uh.edu!cosc19z5
  2. From: cosc19z5@Bayou.UH.EDU (Spasmo)
  3. Newsgroups: comp.lang.c,comp.unix.programmer
  4. Subject: Re: Q: '\n' character
  5. Followup-To: comp.lang.c,comp.unix.programmer
  6. Date: 12 Apr 1996 20:19:43 GMT
  7. Organization: University of Houston
  8. Message-ID: <4kmdsv$ojc@masala.cc.uh.edu>
  9. References: <4kj66f$k0o@ren.cei.net> <4kjh25INNf2e@anvil.ugrad.cs.ubc.ca> <4kko80$8np@news.ld.centuryinter.net> <4kkvvsINN8fs@keats.ugrad.cs.ubc.ca>
  10. NNTP-Posting-Host: bayou.uh.edu
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
  14. : In article <4kko80$8np@news.ld.centuryinter.net>,
  15. : Don & Gayle Peterson <dongayle@centuryinter.net> wrote:
  16. : >It's a shame I didn't see the full original posting, but maybe your
  17. : >solution is 'bullshit' too.
  18. : >A long, long time ago, K&R taught me that the beauty in unix is
  19. : >simplicity: don't re-invent a tool that already exists.  If all the
  20. : >original author wants to do is read 2 (or more) files side by side,
  21. : >what's wrong with good old pr?
  22. : >or, getting fancier, and comparing them, sdiff?...depending on the
  23. : >situation, get nuts, use paste... join...
  24. : >
  25. : >Getting raw side-by-side output from text files at the shell is as
  26. : >simple as:
  27. : >    pr -m file1 file2 ... 
  28. : >or
  29. : >    pr -t -m ....
  30. : >if you don't want the pr header.
  31.  
  32. : I sometimes recommend unix commands myself---for example when someone wanted to
  33. : know how to delete lines from a text stream, I facetiously suggested ``sed''.
  34.  
  35. : However, this is a C newsgroup, not comp.unix.shell. The C language is used in
  36. : all kinds of places. It's somewhat arrogant to suggest UNIX solutions to C
  37. : questions.
  38.  
  39. Actually from where I'm standing this is the comp.unix.programmer newsgroup.
  40. Don't you love crossposting?  It also means that the response was in fact on
  41. topic for us, but apparently not for you--the price of crossposting.
  42.  
  43.  
  44. : >If this requirement is within  C code where the multiple inputs
  45. : >screw up the ability to use pipes, then forgive me for not knowing all
  46. : >the facts. 
  47. : >But,
  48. : >The other response using strlen isn't 'wrong'; there are lots of
  49. : >ways to skin a cat.
  50.  
  51. : Not if you are being paid by the cat. :) And yes, the strlen() response was
  52. : damn wrong. It completely ignored the possiblity that fgets() may return a
  53. : string that doesn't have a newline at the end. Just the sort of useless answer
  54. : that we don't need on comp.lang.c: incorrect, and is directed at the wrong
  55. : question anyway.
  56.  
  57. The strlen() response was right, however it had the possibility of producing
  58. undesired effects under certain conditions.  The user wanted a way to remove
  59. newlines, and the response above did it.  Of course in the case of a overly
  60. long line, the response would remove a valid character--however the fact
  61. remains that it does remove the newline, and with the addition of some minor
  62. code can be made much safer--yet no one has shown the boundary conditions
  63. because it's obvious that they can exist, and they are easy to accomodate.
  64.  
  65. Also given the application, the conditions that would make the strlen()
  66. solution unsafe may not even occur.  So, the details of making the solution
  67. more robust are left out.  Perhaps this is an unwarranted assumption, however
  68. it was an assumption that was made--at least in my case.  I was one of the
  69. folks who suggested the strlen() solution as I use it when needed (with
  70. proper checks of course).  And in case you haven't noticed, the strlen() fix
  71. is directed at newline stripping which *IS* the right question.  Go back
  72. and re-read the original post.
  73.  
  74. And yes there are better solutions to the problem.  I like the strchr solution
  75. posted by a few folks and will probably use that in preference to 
  76. strlen(), however it does not take away from the validity of the original
  77. solution.
  78.  
  79.  
  80. : > have yet to use a version of Unix that will
  81. : >blow up on forcing a null into a returned NULL pointer.
  82.  
  83. : What are you using for a Unix? Are you for real? Boy, you are going to get
  84. : flamed for this.
  85.  
  86. Some of us are adults and don't flame others for what may be considered
  87. improper code.  If anything we use tact and inform others of potential
  88. problems.  If you find the need to flame for what you consider to be
  89. coding mistakes then maybe you should wait until you get out of middle
  90. school before posting on usenet again.
  91.  
  92. [Snip]
  93.  
  94. : >The mere nature of the author's request would indicate that
  95. : >he is looking at text files, (what sense is there doing side-by-
  96. : >sides of binaries?)  So, why not a utility that works with, and 
  97. : >assumes, text?  Unix text files have \n terminators.  Correct me
  98. : >if I'm wrong.
  99. : >
  100. : >So, why write a bunch of lines of _elegant_ code to simply
  101. : >clobber a newline? 
  102.  
  103. : Because it's less typing than the inelegant (and incorrect, unrobust)
  104. : equivalent?
  105.  
  106.  
  107. And using UNIX commands to achieve what you need instead of C is far
  108. more elegant, far less typing, far more robust, and far easier than
  109. any code you can write.  Get a grip the guy above is discussing using
  110. UNIX utilities instead of re-inventing the wheel.  And he's got a very
  111. valid point.  With all the beautiful tools available under UNIX we can
  112. get a lot done without having to write any code.  As it stands people
  113. jump into a compiler to fix problems that can be better fixed without
  114. writing software.  He has a very valid point.  You'd do well to stop
  115. babbling and start listening.
  116.  
  117.  
  118. : >I also notice that your solution does not take into account any
  119. : >output formatting: what happens to the output from f2 when f1 is
  120. : >shorter that f2?  From what I see, it starts looking like output from 
  121. : >f1. 
  122.  
  123. : This was not called for in the informal requirements. In fact, if f1 runs out
  124. : of lines, f2 is flushed left. The original posting (which I'm aware you didn't
  125. : see) had not specified any sort of separator character, though adding one is
  126. : trivial.
  127.  
  128. The original posting also didn't ask for a different way of accomplishing the
  129. desired task, merely for newline removal.  So the supposedly elegant
  130. code that was posted was way off mark.
  131.  
  132.  
  133. [Snip]
  134.  
  135. : >I'm new to this group, and your type of response is kind of scary:
  136. : >does everyone here have a chip on their shoulder?
  137. : >Cut others a little slack!
  138.  
  139. : Incorrect answers, or answers to the wrong question are not helpful to anyone.
  140. : What is scary is that the proliferation of poor answers continues once the
  141. : question has already been beat to death and has been correctly answered by
  142. : people who actually _test_ their code, however trivial, before posting it to
  143. : the newsgroup.
  144. : -- 
  145.  
  146.  
  147. Firstly not everyone is as harsh as the you who criticized everyone's solution
  148. and then took the idiotic step of telling the original poster a solution to an
  149. entirely different problem from what the poster asked about.  The question was
  150. about removing newlines, not about criticizing the means with which he
  151. wrote the code.  Now there's nothing wrong with showing faults or better ways
  152. of doing things if it is done with an iota of *TACT*.  Rampaging about and
  153. insulting others and then posting a solution which ends up in a bad case of
  154. foot in mouth is not in the spirit of usenet.
  155.  
  156. For the record the vast majority of the folks that I have dealt with on here
  157. are very helpful, friendly and knowledgable, unlike you.  You are not helpful,
  158. the "solution" you posted was to an entirely different problem from what was
  159. asked about, you are far from friendly (calling solutions you disagree with
  160. "bullshit" is considered rude), and judging from the fact that you can't even
  161. post an on-topic solution you are far from knowledgable.  I don't claim to be
  162. an expert on anything--I know what I know and I acknowledge when I don't know
  163. something, but I try to help and I am open to advice.  I'd suggest you develop
  164. a sense of humility as well.
  165.  
  166. Finally there is nothing wrong in using different solutions.  Granted some
  167. solutions are better than others and sometimes for brevity a solution is
  168. posted without error checking--but that's because it's an illustration of
  169. how to solve the problem, not a complete solution in itself.  Insulting people
  170. based on solutions you don't approve of just makes you look like a jerk,
  171. especially when you end up posting garbage like you've done now.
  172.  
  173. --
  174.  
  175.                       .A.                        G-Force!  1 AM Houston Time
  176.                      AAAAA                       On the Cartoon Network!
  177.                     AAY:YAA   
  178.                     A':::`A                      This informative message was 
  179.                     :::::::                      brought to you by Spasmo.
  180.                     ::( )::   
  181.                     :::::::
  182.                     :::::::
  183.                     :::::::
  184.                     :::::::     
  185.   .A.          .do:::::::::::bo.          .A.
  186.   AAA       .:::::::::::::::::::::.       AAA
  187.  d:::::::::::::::::::::::::::::::::::::::::::b
  188.  Y:::::::::::::::::::::::::::::::::::::::::::Y 
  189.  `YjY       `:::::::|::|::|:::::::'       YjY' 
  190.                  `::|::|::|::'  
  191.                        |
  192.